Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add process profiler for debugging #6171

Merged
merged 10 commits into from
Jan 31, 2020
Merged

Add process profiler for debugging #6171

merged 10 commits into from
Jan 31, 2020

Conversation

flotwig
Copy link
Contributor

@flotwig flotwig commented Jan 15, 2020

User facing changelog

  • Added debug information about the memory & CPU usage of Cypress, which can be accessed by enabling the cypress:server:util:process_profiler debug stream.

Additional details

looks like this (processes are grouped based on heuristics):

image

users can also choose to dump out ALL process information at every interval by using cypress-verbose:server:util:process_profiler, but this would be a looooot of data

users can also set CYPRESS_PROCESS_PROFILER_INTERVAL to the number of milliseconds between invocations

How has the user experience changed?

see above

PR Tasks

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jan 15, 2020

Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.

  • Please write [WIP] in the title of your Pull Request if your PR is not ready for review - someone will review your PR as soon as the [WIP] is removed.
  • Please familiarize yourself with the PR Review Checklist and feel free to make updates on your PR based on these guidelines.

PR Review Checklist

If any of the following requirements can't be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'.

User Experience

  • The feature/bugfix is self-documenting from within the product.
  • The change provides the end user with a way to fix their problem (no dead ends).

Functionality

  • The code works and performs its intended function with the correct logic.
  • Performance has been factored in (for example, the code cleans up after itself to not cause memory leaks).
  • The code guards against edge cases and invalid input and has tests to cover it.

Maintainability

  • The code is readable (too many nested 'if's are a bad sign).
  • Names used for variables, methods, etc, clearly describe their function.
  • The code is easy to understood and there are relevant comments explaining.
  • New algorithms are documented in the code with link(s) to external docs (flowcharts, w3c, chrome, firefox).
  • There are comments containing link(s) to the addressed issue (in tests and code).

Quality

  • The change does not reimplement code.
  • There's not a module from the ecosystem that should be used instead.
  • There is no redundant or duplicate code.
  • There are no irrelevant comments left in the code.
  • Tests are testing the code’s intended functionality in the best way possible.

Internal

  • The original issue has been tagged with a release in ZenHub.

@cypress
Copy link

cypress bot commented Jan 15, 2020



Test summary

3615 0 47 0


Run details

Project cypress
Status Passed
Commit ae6d2d9
Started Jan 30, 2020 3:50 PM
Ended Jan 30, 2020 3:55 PM
Duration 04:57 💡
OS Linux Debian - 9.11
Browser Multiple

View run in Cypress Dashboard ➡️


This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

@flotwig flotwig changed the title [WIP] Add process profiler for debugging Add process profiler for debugging Jan 15, 2020
Copy link
Member

@jennifer-shehane jennifer-shehane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this and will find this very valuable for helping debug with users.

Can you open a PR within cypress-documentation in debugging page to describe how to print this and update the intervals? https://docs.cypress.io/guides/guides/debugging.html#Troubleshooting-Cypress

Mine printed towards the beginning of launch by default and was already at max CPU from Cypress. Assuming this is printing as expected? This was running in --dev though.

Screen Shot 2020-01-16 at 12 16 17 PM

@flotwig
Copy link
Contributor Author

flotwig commented Jan 16, 2020

Yeah, it will print once when it starts and then at an interval after that, so that's expected. Cypress probably uses a ton of CPU when first starting up.

Opened a PR in docs: cypress-io/cypress-documentation#2407

@flotwig flotwig requested review from jennifer-shehane and a team January 24, 2020 16:50
@brian-mann brian-mann self-requested a review January 24, 2020 23:00
Copy link
Member

@brian-mann brian-mann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on pairing we've determined to intelligently group the various processes based on their user-related usage...

Browser Rules:
- start from the parent cypress process
- walk down to children
- if children matches the launched browser's pid
- consider that the top level process for calculating children

Cypress:
  - parent process
  - Cypress Helper (unknown extra one --type=utility)

Plugins File:
  - Cypress Helper (plugins child process --file XXX)

Desktop GUI: (won't be present in cypress run mode)
  - Cypress Renderer (desktop gui)

Electron: 
  - Cypress Renderer (AUT)
  - Cypress GPU (will still be present in cypress run mode)

Firefox:
  - XXX

Chrome:
  - XXX

ffmpeg
  - XXX

Other:
  - every other process that's been spawned from the parent Cypress PID but is unknown

@flotwig
Copy link
Contributor Author

flotwig commented Jan 29, 2020

right after startup:

image

with desktop-gui:

image

running tests in chrome:

image

running tests in electron:

image

with ffmpeg:

image

@flotwig flotwig deleted the issue-6169-mem-usage-logs branch January 24, 2022 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make it possible to add memory usage info to debug logs
3 participants